Some link layers technologies (or mac technologies), like flash-OFDM developed by Flarion Technologies, Inc., provide a number (we use 16 for illustration but could be more or less) of mac_streams that each can hold a small number (e.g.: 1-10) of packets in them. In some systems of this type there is a potential for anything up to 160 packets or more that could be stored in mac_streams for a particular MN.
IP Packets (e.g.: 40-1500 bytes) are typically segmented into smaller mac_frames (e.g.: ˜24 bytes) within each mac_stream. For purposes of explaining the invention we assume that Link Layer Automatic Repeat Requests (ARQs) includes frames but that they also retain the knowledge of packet boundaries as occurs in some systems. Also, for purposes of discussion, note that a packet may start or end within the middle of a frame.
During a hand-off a Mobile Node (MN) 110, e.g., portable receiver/transmitter, in a mobile (wireless) communication system connects to a new Access Router (AR) 106 and an indication is sent to the old AR 104 used by the MN 108 about the movement. The old AR 104 may then need to forward 126 to the new AR 106 any packets stored for that MN 108 within mac_streams at the old AR 104, and any subsequently arriving packets 122 for that MN 108, e.g., so that they can be transmitted 130 by the new AR 106 to the MN 110. A typical network scenario when using Mobile IP for general mobility management and inter-AR hand-off, is shown in FIG. 1. In FIG. 2, the various types of packet flows for this network configuration are shown and described below. The examples assume a wireless link between the MN and the ARs but can equally be applied to rapid hand-off across other types of access links.                A. Layer 3 Packets 124 already in the L2 mac layer at the old AR 104 for transmission to the MN 108. When the L2 mac layer link to the old AR breaks, then outstanding packets in flow A need to get to the MN 110 via another route 126, 130.        B 122. Layer 3 Packets yet to arrive at the old AR 104 from the HA 102 that need to get to the MN 108 in question. These are in-flight packets from the HA 102 when the MIP hand-off from the MN 108, 110 is received at the HA 102. Flow B packets 122 are therefore those that are received at the old AR 104 between the reception of the MIP hand-off signal at the old AR 104, and the reception of the MIP hand-off signal at the HA 102.        C 126. Layer 3 Packets that need to be forwarded between the old AR 104 and the new AR 106, because the MN 108 in question has left the old AR 104.        D 128. Layer 3 Packets yet to arrive at the new AR 106 from the HA 102, following HA 102 reception of the MIP hand-off signal. These packets 128 will be delivered to the MN 110 at the new AR 106.        E 130. Layer 3 Packets that will be sent to the MN 110 via the new AR 106 L2 mac_layer link.        
Note that in general;Flow C=A+B Flow E=C+D 
In addition, note that whilst the flows described are delineated as packets, it is equally applicable and beneficial to be able to redirect partial packets delineated as mac_frames, when part of a packet as frames has been sent 124 via the old link to the MN 108 before the old link was lost, necessitating the remaining frames in that packet to be forwarded 126 to the new AR 106 for forwarding 130 via the new link.
A range of hand-off scenarios can be envisaged in general, and specifically with this example network scenario, depending on the hand-off triggers from the link-layer and the IP layer, as well as the capabilities of the access links, ARs and MN.
In a L2 Break before Make (L2BBM), where the L3 can only be BBM by implication, the old link is lost, whether by accident or design, and the new link is only available after this event, and not before.
In a L2 Make Before Break (L2 MBB) with L3 BBM, the old and new links are available in parallel but the MN IP stack can only operate over one of these links at the same time and there is a finite time for moving to the new link and configuring the IP stack on the new link.
In a L2 Make Before Break (L2MBB) with L3 MBB, the old and new links are available in parallel as are the MN IP stacks to exploit those links.
Where possible, it is useful to send all packets A 124 and B 122 over the old AR link before hand-off (C=0). However, in hand-off cases, where the old link is lost prematurely, the remaining IP packets and mac_frames at the old AR 104 should be transferred 126 to the new AR 106 so that they can be delivered 130 to the MN 110 over the new link, and hence effect a loss-less hand-off.
A first problem is apparent in that the old AR 104 needs to know what packets/frames must be forwarded 126 to the new AR 106 but only the MN 108 knows with certainty what was actually received 124 from the old AR 104. In addition, the new AR 106 needs to know what packets/frames need to be sent 130 over the new link to the MN 110. This is particularly difficult in cases where the links use Automatic Repeat ReQuest (ARQ) techniques to deliver mac_frames reliably by managing repeat attempts over access links, and by receiving reception acknowledgments from the MN 108, 110. In this case it is necessary for the old AR 104 to send its ARQ state forward to the new AR 106 along with the associated packet/frame data in a process known as Context Transfer. If too much data is sent forward (safety first) then duplicate information may be sent to the MN 108, 110 over the two links (inefficient, reduced throughput and increased latency to other packets for the MN 108, 110) whilst if insufficient data is sent forward then frame and hence incomplete packet loss may result.
A second problem is then clear in that the forwarded packets/frames 126 will take a finite time to reach the new AR 106 link, via a core (e.g., land based) network used to connect ARs 104, 106, during which time packets/frames can't be delivered 130 to the MN 110 even if the new AR mac-layer or IP stack are already configured. This appears to the MN 110 as a lack of connectivity that will temporarily increase the latency of application packets in transit.
A third problem is then apparent if we try to forward over all packets/frames 126, for a specific MN 108 undergoing hand-off, as fast as possible to the new AR 106 to minimize this latency. The result will be a burst of packets on the backhaul uplink from the old AR 104, through the core network, and on the backhaul downlink to the new AR 106. This burst of packets 126 can interfere with other packets e.g. 128 on the links, potentially causing buffer overflows (losses), increased latency and/or reduced throughput for other application flows.
A fourth problem is that the competition between the forwarded packets/frames 126 for the handed off MN 108, 110, and other application flows for other MNs, normally occurs independent of the relative importance of the underlying application QoS (Quality of Service) requirements. If we forward all packets 126, 130 quickly to exploit the new link early, then we maximally affect other application flows, whilst if we smooth the forwarded flow 126, 130 over time then the new link is under-utilized.
In view of the above discussion it becomes apparent that there is a need for improved methods and apparatus for handling hand-offs, which address some or all of the above discussed hand-off problems.